fix: resolve internal tooling refs consistently in pr_validation#121
Draft
hdamker wants to merge 4 commits intocamaraproject:mainfrom
Draft
fix: resolve internal tooling refs consistently in pr_validation#121hdamker wants to merge 4 commits intocamaraproject:mainfrom
hdamker wants to merge 4 commits intocamaraproject:mainfrom
Conversation
…aproject#120) - resolve workflow-owned tooling assets from OIDC job workflow claims when caller permissions allow ID-token access - fall back to legacy camaraproject/tooling@v0 assets for callers that still use the older permissions block - update caller comments and reusable-workflow docs to explain ref resolution and migration behavior
- remove the top-level id-token permission requirement from the reusable workflow - keep OIDC-based ref resolution when caller permissions expose an ID token at runtime - let older callers reach the legacy v0 fallback path instead of failing during workflow startup - clarify the fallback behavior in the reusable-workflow docs
Enables conditional OIDC ref resolution: callers with id-token: write get SHA-pinned checkout, others fall back to legacy v0.
Contributor
Author
|
Converted to draft — see deprioritization rationale on #120. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
enhancement/feature
What this PR does / why we need it:
Makes
pr_validationresolve its internal tooling references (shared actions, linting config) from the same repository and commit that the caller selected, instead of hardcodingcamaraproject/tooling@v0.The reusable workflow now supports two operational models:
OIDC-pinned resolution — Callers that grant
id-token: writeget SHA-pinned internal refs derived from the OIDCjob_workflow_shaclaim. This ensures that the linting config and shared actions match the exact commit the caller selected, enabling branch-based and SHA-based pilot testing.Legacy v0 fallback — Callers that do not grant
id-token: write(i.e., all existing API repository caller workflows) automatically fall back to the currentcamaraproject/tooling@v0behavior. No caller changes are needed for these repositories to continue working.This follows the same OIDC-based ref resolution pattern already used by the release-automation reusable workflow (tooling PR #111), adapted for the permission-inheritance model needed here: the reusable workflow does not declare its own
permissionsblock, so it inherits whatever the caller grants — making the OIDC path available only when the caller opts in.Tested with both models on hdamker/TestRepo-QoD:
id-token: write: https://github.com/hdamker/TestRepo-QoD/actions/runs/22973737137id-token: write: https://github.com/hdamker/TestRepo-QoD/actions/runs/22974036759Which issue(s) this PR fixes:
Fixes #120
Special notes for reviewers:
The reusable workflow's
permissionsblock is commented out (not removed) to document the expected caller permissions. This is intentional — the block cannot be active because GitHub Actions treats an explicit permissions block in a reusable workflow as a hard constraint: any permission not listed is denied, regardless of what the caller grants. Removing it allows conditional OIDC availability based on caller configuration.Changelog input
Additional documentation